-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve UX on modal for deleting an access token #19894
Improve UX on modal for deleting an access token #19894
Conversation
Before, both action buttons where coloured on hover. Otherwise they appeared as ghost buttons. UX tells us, that call to action must not be displayed as ghost button. Using red is perceived as warning colour in Western cultures. It was used for the non-destructive action before. This PR swaps the colour and turns the cancel button into a filled one, so it is saver to do nothing then to accidentally delete an access button. We want the person to do this consciously. In another iteration the wording here could be improved. See the associated issue for further details. Signed-off-by: André Jaenisch <andre.jaenisch@posteo.de>
Oh, that's interesting 😮 Let me fix this. |
Linter does not complain anymore. I was expecting the formatter to pick this up but it didn't. Signed-off-by: André Jaenisch <andre.jaenisch@posteo.de>
@@ -23,7 +23,7 @@ | |||
<div class="content"> | |||
<strong>{{.Name}}</strong> | |||
<div class="activity meta"> | |||
<i>{{$.i18n.Tr "settings.add_on"}} <span>{{.CreatedUnix.FormatShort}}</span> — {{svg "octicon-info"}} {{if .HasUsed}}{{$.i18n.Tr "settings.last_used"}} <span {{if .HasRecentActivity}}class="green"{{end}}>{{.UpdatedUnix.FormatShort}}</span>{{else}}{{$.i18n.Tr "settings.no_activity"}}{{end}}</i> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can back this out if required. But double spaces itched me here. Is it about giving the icon some space?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not unusual to sneak in some small code-style into a PR.
@@ -23,7 +23,7 @@ | |||
<div class="content"> | |||
<strong>{{.Name}}</strong> | |||
<div class="activity meta"> | |||
<i>{{$.i18n.Tr "settings.add_on"}} <span>{{.CreatedUnix.FormatShort}}</span> — {{svg "octicon-info"}} {{if .HasUsed}}{{$.i18n.Tr "settings.last_used"}} <span {{if .HasRecentActivity}}class="green"{{end}}>{{.UpdatedUnix.FormatShort}}</span>{{else}}{{$.i18n.Tr "settings.no_activity"}}{{end}}</i> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not unusual to sneak in some small code-style into a PR.
{{/* | ||
The wording here is a bit confusing. | ||
The action asks for deleting an access token. | ||
Confirming is therefore the destructive option and | ||
should be deemphasized because it cannot be undone. | ||
*/}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we leave comments like this in the code. Haven't seen it before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was on the fence. But then looking at the template below where „yes” was in red
and no
was marked up I thought it warranted an explanation.
Now I don't want to make contributors hunt the code history to find the motivation. And the comment wouldn't get rendered out (I checked). Aside, Go files have comments for functions.
I don't mind if I shall remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh would be better if the comment wouldn't be rendered to the client(if anyone wants to find this motivation, opting to go search it in the code should be de-facto default).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the template comments are rendered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They aren't. I double checked.
{{.i18n.Tr "modal.no"}} | ||
</div> | ||
<div class="ui green basic inverted ok button"> | ||
<div class="ui red basic inverted ok button"> | ||
<i class="checkmark icon"></i> | ||
{{.i18n.Tr "modal.yes"}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are improving UX already, wouldn't it be better to use No -> Cancel
and Yes -> Delete
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would trigger a change in the translation. I wrote my thoughts in #3589 (comment)
Therefore, the PR only mentions, it is associated with the issue, i.e. not a complete fix.
How long does it take to complete a translation cycle?
I would fill a follow-up PR to adjust the wording (as I mentioned, I would highlight that the change cannot be undone in this case). Inconsistency in modals are also discussed in #3605
I'm not sure, whether the Template should become a Vue component, for example. Or be made reusable.
I can see arguments pro and con.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"How long does it take to complete a translation cycle?"
PR changes the locale_en-US.ini
-> PR gets merged -> 24h (at most) -> text gets translated in crowdin.com -> translation gets approved -> 24h (at most) -> (auto) commit & push the translation.
So, if there are active proof-readers, in (at most) 48h the translations can be updated, and there is still enough time before Gitea 1.17's release.
ps: I think the text could be updated directly without considering the translation cycle. Personally I always update texts if they need to be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#code-review
Make small pull requests. The smaller, the faster to review and the more likely it will be merged soon.
I will brew a follow-up PR with the wording changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is already incredibly small.
This is rather meant for bigger changes, i.e. PRs that change 400+ lines.
* giteaofficial/main: Prevent NPE whilst migrating if there is a team request review (go-gitea#19855) [skip ci] Updated translations via Crowdin Add support for rendering terminal output with colors (go-gitea#19497) Fix viewed images not loading in a PR (go-gitea#19919) Remove out-dated comments (go-gitea#19921) Automatically render wiki TOC (go-gitea#19873) Improve wording on delete access token modal (go-gitea#19909) [skip ci] Updated translations via Crowdin Add breaking email restrictions checker in doctor (go-gitea#19903) Ensure minimum mirror interval is reported on settings page (go-gitea#19895) Improve UX on modal for deleting an access token (go-gitea#19894) update discord invite (go-gitea#19907) Only log non ErrNotExist errors in git.GetNote (go-gitea#19884) [skip ci] Updated translations via Crowdin Update frontend guideline (go-gitea#19901) Make AppDataPath absolute against the AppWorkPath if it is not (go-gitea#19815)
* Improve UX on modal for deleting an access token Before, both action buttons where coloured on hover. Otherwise they appeared as ghost buttons. UX tells us, that call to action must not be displayed as ghost button. Using red is perceived as warning colour in Western cultures. It was used for the non-destructive action before. This PR swaps the colour and turns the cancel button into a filled one, so it is saver to do nothing then to accidentally delete an access button. We want the person to do this consciously. In another iteration the wording here could be improved. See the associated issue for further details. Signed-off-by: André Jaenisch <andre.jaenisch@posteo.de> * Use tabs instead of spaces. Linter does not complain anymore. I was expecting the formatter to pick this up but it didn't. Signed-off-by: André Jaenisch <andre.jaenisch@posteo.de> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Associated issue #3589
I am not sure, whether this PR resolves it completely. I could very well
imagine improving the wording here.
Before, both action buttons where coloured on hover. Otherwise they
appeared as ghost buttons. UX tells us, that call to action must not
be displayed as ghost button.
Using red is perceived as warning colour in Western cultures. It was
used for the non-destructive action before. This PR swaps the colour
and turns the cancel button into a filled one, so it is saver to do
nothing then to accidentally delete an access button. We want the
person to do this consciously.
In another iteration the wording here could be improved. See the
associated issue for further details.
Another improvement could be including the name of the token.
Imagine you are interrupted and come back after a pause. Could
you always tell, which token is about to be deleted here?
I don't know, how well this would work with internationalisation, so
I left it open.
Signed-off-by: André Jaenisch andre.jaenisch@posteo.de